-
Notifications
You must be signed in to change notification settings - Fork 6.1k
Simplify RequestMatcherDelegatingAuthorizationManager.Builder matcher registration #13110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
dac9fd0 to
652b526
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @evgeniycheban, I have left feedback inline.
Can you please ensure that the @since tags are updated to 6.2 because we already have a release candidate for 6.1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The requestMatchers method should keep the same behavior as AbstractRequestMatcherRegistry by creating a MvcRequestMatcher if possible and use AntPathRequestMatcher as a fallback.
Line 181 in 1631cac
| public C requestMatchers(HttpMethod method, String... patterns) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @marcusdacoregio, thanks for the review. I'm not sure if it would be a good idea to propagate an ApplicationContext to this builder, maybe we could create here AntPathRequestMatcher by default
and let the user register MvcRequestMatcher using requestMatchers(RequestMatcher... matchers).
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are right, can you make that behavior explicit in the javadoc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reflected this behavior in the javadoc and updated @since tags to 6.2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @evgeniycheban, I am concerned about having the ant matcher the default if Spring MVC is in the classpath. This deviates from the default that Spring Security adopted in 6.0. For now, what if requestMatchers only takes a RequestMatcher instance? We can think more (in another issue) about how to communicate the MVC nuance to the builder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @marcusdacoregio, makes sense, let's stay only with requestMatchers(RequestMatcher... matchers) for now and think about supporting MvcRequestMatcher in the future releases. I will update the PR soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the PR.
|
Thanks @evgeniycheban, this is now merged into |
Simplify RequestMatcherDelegatingAuthorizationManager.Builder matcher registration
Closes gh-11624